1. 排队逻辑

平台内部接收到任务后，如果用户选择的卡有资源，即至少有节点上具备足够多数量的空闲GPU，则调度任务到对应节点上执行；如果没有资源则排队等待，等有空余资源时，从满足条件的任务中按开始排队的时间先后决定资源分配[1]。

排队的时间和申请GPU卡的类型、数目，以及当前系统的资源空闲情况有关，可以通过https://bitahub.ustc.edu.cn/resources 了解当前时刻系统的资源使用情况。

2. 运行前准备

平台内部采用Docker容器架构，任务将首先拉取Docker镜像，视镜像的大小而决定这一步的时间，然后启动Docker容器，启动的同时将用户独有的存放在共享存储上的目录映射到容器内部（也就是用户程序所能看到的 /code， /data，/model， /output这4个目录），最后执行用户设定的启动命令。

3. 与任务进行交互

任务启动执行后，与用户的交互主要通过日志，任务打印输出到stdout或stderr，用户通过平台的网页查看日志。

如果程序支持TensorBoard，并且把日志写入到 /output 目录，则还可以在平台上启动Tensorboard后端服务查看内容。

4. 任务结束

用户设定的启动命令运行结束即意味着任务结束。结束后Docker容器将消失，除了/data，/model， /output这三个目录，写入到其他目录的内容都将随之消失。

注：如果是调试任务，写入 /code的内容也会被保存。

[1] 这样的调度方式一定程度上是偏好于小任务的。举例，集群资源很紧张时，8卡任务尽管早早就排队了，但1卡任务释放后空余的GPU将会被其后的1卡任务继续占用，而并不会为这个8卡任务预先保留资源，导致8卡任务排队会更久。调度方式的选择有集群整体效率和实现难易度的考虑，这里不再展开讨论。另外，这里的排队时间，不一定是指任务提交的时间，如果你在10分钟内没得到资源，那你的排队时间会被重置。也就是说，早提交的任务不保证优先得到资源，你也可以认为是随机模式，只是提交早的任务，抽签的机会更多了些。